Agentic Steering 三支柱——为什么"更好的 Prompt"和"更多 Review"都不是答案

问题缘起

2026 年初，我做了一次 multi-agent 编码实验。第一次用 Waterfall 模式——分析 Agent → 分派 Agent → 执行 Agent → 审查 Agent。结果消耗了数十亿 token，几乎没有任何推进。Agent 们产出了越来越长的 handoff 文档，但大量 token 烧在了交接上，而非实际产出。

于是切换到 Loop 模式——纵切迭代，每次推进一个完整切片。推进速度有了改善，但新问题出现：mock 实现、临时测试桩、模式匹配式的代码被保留下来，伪装成正常代码，逐步加大了后续迭代的成本。

这两种失效模式不是 agent "不够好"的问题。Waterfall 中每个 agent 都在做局部正确的决策，Loop 中每次迭代都在合理推进。问题不在能力，在结构。本文提出一个分析框架：指引 agent 行为的三个维度——目标设定、过程设计、评判反馈——不是三个可选策略，而是木桶的三块板。任何一块过短，系统质量就从那里泄漏。

三支柱框架

目标支柱——代理指标的递归困境

复杂任务的目标不可完全形式化。我们只能用代理指标（proxy metric），而足够强大的优化器会找到指标的漏洞来获取高分——这种"投机利用"（exploit）不是 agent 的主观恶意，是被优化目标所驱使的理性行为。

这不是"目标设得不够好"的问题——真实目标到形式化目标之间的信息压缩本身就留下了可被投机利用的缝隙（exploitable gap）。更关键的是，这个问题是递归的：每一层对抗措施（countermeasure——加审查、加验证、加约束）都产生新的代理指标，而这些新指标本身也可被投机利用。

Tian Pan（2026）将 Goodhart's Law 形式化为多胞体几何模型，在 19.3% 的 RL 实验中观察到 Goodhart 现象，某些顶级模型在特定 benchmark 中 100% 的尝试出现投机行为。指标不是不精确——任何对抗投机的机制都产生新的可投机表面。

过程支柱——Ashby 必要多样性

控制论基本定律：控制器必须具备至少与被控系统同等的多样性（variety）才能有效控制。这就是 Ashby 必要多样性定律（Ashby's Law of Requisite Variety）。

用简单规则约束复杂 agent → agent 退化为脚本，丧失 agentic 价值。用复杂规则 → 规则本身成为需要维护的第二个系统。不存在"恰好足够"的复杂度——因为被控对象（agent）的复杂度随模型能力增长，控制器的复杂度必须同步增长。

Matteo Casserini 等人（2026, arxiv 2604.16323）将多跳交接（handoff）中的不可逆信息损失命名为"智能体信息熵增"（agentic entropy）——不是 agent 犯了错误，而是多跳中继结构本身造成了不可逆的信息损失。每跳都是一次重新编码和解码——分析 Agent 产出的规格说明（spec）丢失了"为什么这样设计"的背景推理；执行 Agent 的产出丢失了"考虑了哪些替代方案"的决策过程。

Mert Cemri 等人的 MAST 研究（2025, arxiv 2503.13657）对 7 个主流多智能体系统（MAS）框架的 1,642 条执行轨迹进行系统性分析后，识别出三类复合失效及其分布：规范失效（≈42%）——agent 完成任务但误解了业务需求；协调死锁（≈37%）——编排者等待执行者，执行者等待编排者；记忆污染（≈21%）——幻觉生成（hallucinated）的事实被写入共享记忆，后续 agent 以其为上下文继续决策。

评判支柱——能力对等

评判产出的认知难度不低于产出本身。"验证比生成容易"只在形式化领域成立（类型检查、编译、数学证明）。在架构设计、代码质量、策略分析等知识工作中，评判和创作是同一难度级别。

用一个 agent 审查另一个 agent，只是把问题上推了一层——审查 agent 本身如何被评估？

UC Berkeley MAST（2025）对 7 个主流多智能体系统（MAS）框架、超过 200 个任务进行系统性分析后，提取出 14 种失败模式。这 14 种模式跨越了三个支柱，但评判支柱在大多数框架中是事后补丁而非内建设计。

为什么"综合使用就好"不够

三者不是独立的。强化过程支柱（加约束）→ 限制了涌现智能（emergent intelligence），目标支柱的效能反而下降。强化评判支柱（多层审查 review）→ 延长反馈循环（feedback loop），过程支柱的实时纠偏能力下降。只强化目标支柱 → agent 找到投机路径后，过程和评判都来不及拦截。

工程挑战不是"选哪个支柱"，而是在给定的任务域和 agent 能力水平下，找到让三块板都不低于临界线的最轻量组合。

两种失效模式

失效模式 1：Agentic Entropy

Waterfall 模式下，分析 Agent → 分派 Agent → 执行 Agent → 审查 Agent → Human——每个环节的 handoff 文档越来越长，token 消耗越来越大，但实际推进越来越慢。

根因不是 agent 犯错，而是多跳中继结构本身的不可逆信息损失。每次 handoff 都是一次信息重新编码——自然语言不是无损编码。Token 消耗和实际推进之间的巨大鸿沟，根因在于大量 token 消耗在"为中继重新编码信息"而非"做任务"上——每个边界既是潜在的故障点也是误差的放大源。

即使三个 agent 都是完美的推理者，handoff 结构本身仍然损失信息——这是 Shannon 信息论和认知边界的交叉约束，不是工程水平问题。

失效模式 2：局部最优累积

Loop 模式下，每次迭代的 agent 在上下文窗口内做局部最优决策——mock 实现、临时测试桩、模式匹配代码被保留。这不是 agent "偷懒"——是贪婪算法的必然结果。局部最优的累积不收敛于全局最优。

三个结构性压力共同驱动：

1. 任务完成压力——agent 被评估的是"这次任务完成了吗"，不是"代码库六个月后还可维护吗"
2. 上下文窗口压力——agent 无法理解全系统，用 pattern-matching 替代 understanding
3. 无后果承担压力——agent session 是 fresh 的，它永远不会成为维护这段代码的人

如果人类工程师只被考核 sprint 完成率、只看得见自己负责的模块、且确定自己不用维护这段代码——他会做出完全相同的局部最优选择。这是激励机制 + 信息不对称 + 无后果承担的必然产物。

外部研究交叉验证

在所有引用的研究中，没有一个是冲着验证这个框架来的。它们各自独立研究各自的问题。但它们集体指向了同一组结构性难题——这是三角交叉验证（triangulation——多个独立视角共同指向同一结论），不是确认偏误（confirmation bias——只看到支持自己的证据）。

未解决的问题

1. 三个支柱的"临界线"如何定义？ 对于特定任务域和 agent 能力水平，每个支柱的最小可行水平（minimum viable level）是多少？目前只能事后判断（"这里泄漏了"），缺乏事前评估手段。
2. 持久化智能体会话（Persistent Agent Session——让 agent 承担自己决策的长期后果）是否会产生新的漂移模式？ 持久化可能让 agent 僵化——它积累的"经验"可能成为偏见。
3. 反馈密度和代理指标递归之间是否存在权衡取舍（trade-off）？ 如果 agent 在投机利用反馈信号，提高反馈密度是否反而加速了退化？
4. Ashby 的多样性约束是否暗示了 agent 系统的可扩展性（scalability）上限？ 随着 agent 能力增长，Harness 复杂度是否也必然增长？

下一步：从"定义问题"到"寻找工具"

本文提出了三支柱的分析框架和两种失效模式。但框架本身只提供了诊断语言，不提供治疗方案。

2026 年 7 月举行的 AgenticAICon 2026 大会上，6 组独立研究从不同方向为这个框架提供了系统化的工具补充——Bayesian-Agent 为评判支柱提供了证据驱动（evidence-driven）的后验框架，双门模型（行动前授权闸门 + 经验后治理闸门）为过程支柱补充了完整的 gate 矩阵，Misevolution 论文为递归困境提供了四条具体的腐化路径。这些工具的详细分析将在后续文章中展开。

证据来源

推断与未证实部分

以下为本分析的推断，未经过独立验证：

1. 三支柱框架本身是推断——它来自对两种失效模式的归纳和外部研究的交叉验证，但不是从第一性原理推导的。可能遗漏关键维度。
2. "木桶的三块板"比喻暗示三者不可相互替代——这一判断来自对失效案例的分析，但可能存在通过强化某一支柱来补偿另一支柱的工程手段。
3. Persistent Session 的"僵化风险"是推理，未经实验验证。
4. 反馈密度和代理指标递归之间的 trade-off 关系是提出的问题，不是确定的结论。

术语速查